\documentclass{article}
\usepackage[dutch]{babel}
\usepackage{graphicx} % Voor invoegen van afbeeldingen en grafiek
\usepackage{listings}
\usepackage{float} 
\usepackage{alltt} 
\usepackage{caption}
\usepackage[usenames,dvipsnames]{color} 

\lstset{
basicstyle=\footnotesize,
numbers=left,
stepnumber = 5,
numberstyle=\footnotesize
}

\newcommand{\TRule}{\rule{\linewidth}{0.5mm}}

\author{
{Chris Bovenschen}\\
{Eenass Butrus}\\
{Gail Martoidjojo}\\
{Fredo Tan} 
}
\title{Gedistribueerde Systemen \\ Distributed Systems Chat \\ Plan van Aanpak}
\date{\today}

\begin{document}
\input{./titel.tex}

\newpage
\tableofcontents

\newpage
\section{Inleiding}
Voor het vak Gedistribueerde Systemen houdt de practicumopdracht in: het ontwerpen, bouwen en testen van een server voor een chatsysteem. De client en de control server is reeds door de practicumleiding ontwikkeld. De server zal onderdeel zijn van de backbone van servers voor het gedistribueerd systeem.

Het systeem moet kunnen communiceren volgens het gegeven protocol. Het protocol maakt gebruik van UDP, waarmee er berichten gestuurd worden van de ene naar de andere server. Dit kan gebeuren zonder dat daarvoor een speciale verbinding of een datapad moet worden opgezet. In tegenstelling tot TCP is UDP een niet-betrouwbaar protocol, maar dankzij een lagere overhead is dit protocol wel sneller.

Het chatsysteem bestaat uit clients, servers en een control server. De servers en clients kunnen op verschillende platforms ontwikkeld  worden, maar moeten wel met elkaar kunnen communiceren en samenwerken. Het is de bedoeling dat er een betrouwbaar en robuust systeem wordt gebouwd, zodat na het uitvallen van een bepaald onderdeel er herstel plaatsvindt. Het gegeven protocol zal precies gevolgd moeten worden, opdat de server kan samenwerken met de rest van het geheel van clients, andere servers en de control server.

\section{Implementatiekeuze}
We hebben voor de programmeertaal Python gekozen. Python is een stabiele en overzichtelijke taal dat platformonafhankelijk, robuust en objectgeori\"enteerd is. Hedendaags wordt het als een succesvolle taal beschouwd waarvoor veel support is. Twee leden van de groep hebben al ervaring met deze taal en de andere twee willen graag meer ervaring op doen in het gebruik van Python. Daarnaast wordt er Python toegepast bij de practicumopdrachten van Statistisch Redeneren. 

Het platform waar we op werken is Linux. Op dit besturingssysteem zijn alle programmeerbenodigdheden die wij gebruiken aanwezig. Uiteindelijk moet het chatsysteem op de computers van de Universiteit van Amsterdam werken, die tevens Linux draaien.

\newpage
\section{Analyse van het protocol}
\subsection{Netwerkarchitectuur}
Het systeem bestaat uit een control server, servers en clients. 
De control server houdt bij welke servers er online zijn. Als een nieuwe server zich aanmeldt, geeft de control server dit met behulp van adressen door aan de overige bestaande servers; daarnaast wijst hij ook willekeurig een parent toe aan de nieuwkomer.
Clients kunnen  tegelijkertijd met maar \'e\'en server communiceren en de servers kunnen zo een boomstructuur vormen. In onderstaand figuur \ref{fig:topologiecompleet} is weergegeven hoe het systeem in elkaar zit. 

\begin{figure}[htbp]
	\centering
		\includegraphics[scale=0.4]{topologiecompleet.png}
	\caption{Topologie}
	\label{fig:topologiecompleet}
\end{figure}

% Aanname: parent server kunnen zelf ook clients hebben ? ? ? ? 

Servers 1, 2 en 3 zijn parent servers en zijn rechtstreeks verbonden met de control server. Er zijn 2 child servers, namelijk 2.1 en 2.2. Parent servers kunnen verder ook zelf clients hebben, maar laat bovenstaande afbeelding dit achterwege. De richting waarnaar de pijltjes toewijzen (bijvoorbeeld: server $\rightarrow$ client) geven aan dat, in dit voorbeeld, de server bijhoudt welke client het is. In het geval van control server $\rightarrow$ server, geeft de afbeelding weer dat de control server de server bijhoudt door middel van continu pingen (type 140 en 150 van de berichten die verstuurd kunnen worden). Een lijn betekent slechts dat de entiteiten van elkaar op de hoogte zijn. Dus server 1, 2 en 3 weten van elkaar dat ze bestaan. Het chatsysteem kent drie soorten van communicatie: tussen server en control server, tussen twee servers, tussen client en control server en tussen server en client. Onderstaand schema \ref{fig:schema} geeft weer volgens welke berichttypen er communicatie plaatsvindt. Een pijl vanuit de client naar de server toe betekent dat de client een bericht stuurt naar de server. Een pijl dat een cirkel vormt wilt zeggen dat er communicatie tussen servers onderling plaatsvindt.

\begin{figure}[htbp]
	\centering
		\includegraphics[scale=0.60]{schema.png}
	\caption{Protocolschema}
	\label{fig:schema}
\end{figure}

\subsection{Server-server}
De control server zorgt ervoor dat de servers elkaar kunnen vinden. Een nieuwe server meldt zich daarom eerst aan bij de control server die een willekeurige server in het netwerk kiest als die aanwezig is en zijn adres terug stuurt. Deze gekozen server wordt de parent van de nieuwkomer, waarna de child zich ook daar aanmeldt (berichttype 600). Indien er nog geen servers waren, wordt de nieuweling de wortel van de boom van servers. Verder stuurt deze laatste een lijst van zijn clients naar de child (berichttype 110) als de child zich heeft aangemeld bij de parent. Onderstaande afbeelding \ref{fig:server} geeft weer volgens welke berichttypen de servers communiceren.

\begin{figure}[!h]
	\centering
		\includegraphics[scale=0.55]{server.png}
	\caption{Protocol server}
	\label{fig:server}
\end{figure}

% Kan het zo zijn dat de nieuwe server al kinderen en clients heeft ? ? ? ?

Stel dat \'e\'en van de children van een server uitvalt.

\begin{figure}[htbp]
	\centering
		\includegraphics[scale=0.4]{topologiechildlost.png}
	\caption{Offline child server}
	\label{fig:topologiechildlost}
\end{figure}

Om op de hoogte te blijven van online entiteiten wordt er continu gepingd (berichttype 140 en 150). Als een server merkt dat \'e\'en van zijn children niet meer reageert op pings, kan hij er van uit gaat dat die child offline is. Die child wordt dan verwijderd uit de lijst van online servers. Communicatie wordt namelijk verbroken; dit wordt ook doorgegeven aan de control server. Clients van de offline child worden afgemeld. 

In geval van een uitgevallen parent wordt de control server eveneens op de hoogte gesteld. Deze kiest een nieuwe parent uit en stuurt diens adres naar de child server(s). Alles (dus ook de clients) van de oude parent komen te vervallen, dus deze worden afgemeld. Clients van de nieuwe parent worden doorgegeven aan de child server(s) en omgekeerd ook. Dit onderwerp past waarschijnlijk het beste onder de subsectie ``client-server'', maar het komt hier eenmaal ter sprake. 

\subsection{Client-server}
Als een client zich wilt aanmelden, doet hij dat eerst bij de control server met behulp van berichttype 610. Deze reageert door het adres van een willekeurige server in het netwerk terug te sturen, hiervoor wordt berichttype 611 gebruikt. Vervolgens registreert de client zich bij de toegewezen server (berichttype 100) en deze server geeft aan het netwerk door dat er een client is toegevoegd (110).  

Naast normale clients zijn er ook beheerders. Elke server houdt een lijst bij van de namen en wachtwoorden van de beheerders voor die specifieke server. Een beheerder vraagt niet eerst bij de control server om het adres van een server maar registreert zich rechtstreeks bij een server door een 100-bericht te versturen met daarin zijn naam en het wachtwoord. 

De server hoeft niet altijd een client te accepteren, de server mag ook clients weigeren. Bijvoorbeeld als de naam van de client niet uniek is of als het opgegeven wachtwoord ongeldig is. In deze gevallen reageert de server niet met een 500-bericht maar met een bericht van type 510, ``Registratie mislukt''. Verder kunnen clients ook offline gaan, hiervoor sturen ze een 120-bericht naar de server waar ze aangemeld zijn. De server reageert dan met een 130-bericht; verder wordt de rest van de servers ook op de hoogte gesteld met dit type bericht. Het kan ook dat een client zich niet netjes afmeldt maar opeens niet meer reageert. Als de client al een halve minuut stil is dan wordt er gepingd. Reageert de client hier niet op, dan is hij waarschijnlijk offline en wordt de client zodoende afgemeld.

\newpage
\subsection{Onduidelijkheden}
Tot nu toe is er nog een hele kleine onduidelijkheid. Kan een nieuwe server al children en clients hebben? Waarschijnlijk kan er een situatie bestaan waarbij een parent uitvalt, waardoor zijn children met bijbehorende clients worden aangemeld bij een andere server. Deze wordt dan de parent server. Dit is een geval waarbij een ``nieuwe'' server met bijbehorende clients en eventuele children zich aanmeldt bij een parent.

\section{Schema van te schrijven software}
Het programma gaat bestaan uit verschillende threads zodat er geluisterd kan worden naar de poorten en berichten gemaakt kunnen worden terwijl er ook op tijd gereageerd wordt op een ping. De implementatie begint bij de main, waar de threads worden opgezet en het configuratiebestand wordt uitgelezen. De threads schrijven naar aparte logbestanden. De threads zijn als volgt: 

\begin{itemize}
  \item Listener thread: \\Deze luistert constant naar de poort gespecificeerd in het configuratiebestand en stuurt de ontvangen berichten door naar de message handler thread.
  \item Message handler thread: \\Deze handelt zijn ontvangen berichten af op basis van FIFO door middel van een queue waar telkens \'e\'en van wordt behandeld. Indien deze thread moet antwoorden zal hij een bericht geven aan de message sender thread. De workload op deze thread zou te hoog kunnen worden, maar de verwachting is niet dat dit zo zal zijn gegeven de omvang van de opdracht.
  \item Message sender thread: Deze behandelt de uitgaande berichten. Er worden berichten gemaakt volgens het protocol en deze worden gestuurd naar het adres dat te vinden is in de database.
  \item Pinger thread: Deze houdt in de gaten of er een ping verstuurd moet worden naar een verbinding en indien hier sprake van is wordt dit verstuurd met behulp van de message sender thread. In het geval dat er niet snel genoeg wordt gereageerd, wordt de connectie uit de database gehaald en wordt er opnieuw een bericht via de message sender thread gestuurd betreffende het verbreken van de verbinding.
  \item Log thread: Deze zorgt ervoor dat er een logbestand te verkrijgen is waar de gebeurtenissen op volgorde staan.
\end{itemize}

\newpage
\section{Groepsverdeling}
De groep bestaat uit vier studenten Informatica. We spreken met elkaar af tijdens de beschikbare inloopsessie op dinsdag van 11.00 tot 12.45. Indien nodig wordt er uiteraard ook buiten de practicumgelegenheid gewerkt. Bestanden worden uitgewisseld door middel van versiebeheersysteem Subversion.

Nu is er nog geen sprake van een concrete taakverdeling. Iedereen zal werken waar het nodig geacht wordt. Daarnaast is het de bedoeling dat een lid een ander lid helpt met een kwestie als er die persoon ergens tegen aanloopt. Verder zal elk lid zijn bijdrage leveren aan het verslag.

Als er sprake is van een groepslid dat ziek is zullen de overige leden gewoon doorgaan met de werkzaamheden, dusdanig om het verlies te minimaliseren. Ondertussen wordt het zieke groepslid natuurlijk constant op de hoogte gehouden van de vorderingen binnen het project.

\section{Tijdsplanning}
Wij zullen ons proberen te houden aan de tijdsplanning die te vinden is op Blackboard. Het plan van aanpak moet maandag 9 april af zijn. Op dinsdag 10 april vindt er een bespreking met de docent en assistent plaats naar aanleiding van deze plan van aanpak. 

In dezelfde week beginnen we met het produceren van code. Het idee is dat we ongeveer drie weken de tijd krijgen om te werken aan de implementatie. In week 15 wordt er een begin van de implementatie gemaakt. De main die dan het configuratiebestand kan inlezen, listener thread en de log thread worden dan geschreven. Daarnaast wordt een database van clients en servers opgezet. De week erna is het de bedoeling dat we goed op weg zijn met de implementatie en worden de taken van vorige week afgemaakt als die nog niet af zijn. Verder wordt de message handler thread geschreven en een begin gemaakt aan de message sender thread. De afronding van de implementatie vindt dan plaats in week 17. De message sender thread en pinger thread worden gemaakt en de overige onderdelen die nog niet klaar zijn worden afgerond. Volgens de planning op Blackboard is er in week 18 geen practicum. Deze week zou gebruikt kunnen worden voor de implementatie mits meer tijd nodig blijkt te zijn. 

Week 19 is ervoor om de demonstratie voor te bereiden en het schrijven van het verslag. Een werkende binary moet worden ingeleverd in de week daarna op maandag 16 mei. De volgende dag zullen we onze implementatie gezamenlijk testen tijdens het practicum. Daarnaast wordt het verslag afgemaakt en worden nog enkele verbeteringen aan de code toegevoegd. De deadline voor het inleveren van de gehele opgave (code, documentatie en verslag) is maandag 21 mei om 23.59.

\section{Verbeteringen}
Op dit moment zijn hebben wij geen verbeteringen in gedachte wat betreft de opdracht.

\end{document}
